[Draft] Add support for standalone callbacks#10192
Conversation
0d3b36b to
ad9f7cb
Compare
edb387a to
40f2f7e
Compare
| "/temporal.api.workflowservice.v1.WorkflowService/PollNexusOperationExecution": 4, | ||
| "/temporal.api.workflowservice.v1.WorkflowService/PollActivityExecution": 4, // TODO(saa-preview): should it be 4 or 3? | ||
| "/temporal.api.workflowservice.v1.WorkflowService/PollActivityExecution": 4, // TODO(saa-preview): Should it be 4 or 3? Same PollCallback. | ||
| "/temporal.api.workflowservice.v1.WorkflowService/PollCallbackExecution": 4, |
There was a problem hiding this comment.
it seems the other APIs added Poll and Describe to ExecutionAPICountLimitOverride?
There was a problem hiding this comment.
Good catch! Yes, it looks like they do. I only updated this file because some unit tests failed, but it looks like there's some more meaningful choices to consider.
I'll take a closer look and pattern things after the Activity endpoints, since we'd want to modify how the Callback APIs are counted for the same reasons.
| cb.recordAttempt(event.Time) | ||
| now := ctx.Now(cb) | ||
| cb.recordAttempt(now) | ||
| cb.LastAttemptFailure = nil |
There was a problem hiding this comment.
This should set CloseTime as it's a terminal state. Also could to have covered by a test somewhere.
| type library struct { | ||
| componentOnlyLibrary | ||
|
|
||
| config *Config |
| return missingRequiredFieldError("Namespace") | ||
| } | ||
| return nil | ||
| } |
There was a problem hiding this comment.
Some things I'm missing:
- is the
run_idvalidation; see use ofuuid.Validate identitylength validationreasonlength validation- SANO also has a
if ref.NamespaceID != namespaceIDcheck for the polling token
| if completion.GetSuccess() != nil && completion.GetFailure() != nil { | ||
| return serviceerror.NewInvalidArgument("Completion must have exactly one of success or failure set, not both.") | ||
| } | ||
| // Validate the size of the completion is reasonable. |
There was a problem hiding this comment.
nit: I don't think this comment adds anything, the method name is already very expressive
| return missingRequiredFieldError("Namespace") | ||
| } | ||
| return nil | ||
| } |
There was a problem hiding this comment.
I'm not seeing any tests for the validations. I think those are valuable. See temporal/chasm/lib/nexusoperation/validator_test.go for an example.
| } | ||
|
|
||
| // ScheduleToCloseTimeout | ||
| if req.GetScheduleToCloseTimeout() == nil || req.GetScheduleToCloseTimeout().AsDuration() <= 0 { |
There was a problem hiding this comment.
I wonder if we want a MaxOperationScheduleToCloseTimeout? SANO has it.
| } | ||
| } | ||
|
|
||
| // Create the CHASM Callback in so-called "standalone" mode, where it will be the root |
There was a problem hiding this comment.
nit: I don't think we need "so-called" and quotes; "standalone" for all the standalone features is part of the public-facing wording.
What changed?
Adds support for "standalone" callbacks. Today, the CHASM
Callbackcomponent is used to deliver an arbitrary payload to a URL. (e.g. when a Workflow has completed.) As part of supplying the Nexus Connector Foundations, this feature adds CRUD operations on callbacks directly. So callers can invokeStartCallbackExecution(...)and get the durability guarantees to ensure that the callback actually gets invoked.Why?
The primary (only?) use-case for this is for completing Nexus operations. With this capability, a Handler can implement a Nexus operation outside of Temporal. And when that operation completes, simply call
StartCallbackExecution(...)with the right callback URL and Token. Then the CHASMCallbackmachinery will attempt to deliver the result for the Nexus operation. (Rather than, say, the Nexus operation to be implemented as a Workflow that is separately polling the async or out-of-band process.)How did you test it?
Potential risks
TBD. Will need to ask around.